Beyond the Breakthrough: The Product Delivery Gap
From Prototype to Practice
Ava Binao Guo, Technical Product Manager & UX Strategist | Health Technology, Rehabilitation Systems, Immersive Design
Interview by Ouissam Brahmi
Professional Perspectives | May 2026
Tell us about yourself and your path into digital health.
My name is Ava. My path into healthcare technology has not been linear. I started with a Bachelor's in Engineering and Industrial Design from the University of Liverpool, which gave me a foundation in how to think about design and function together. From there, I moved into product management for a smart rehabilitation system, where I led the development of patented rehabilitation products and their deployment across hospitals and rehabilitation centers.
I then pursued an MPA in Health Policy and Management at NYU, where I developed a deeper understanding of how healthcare policy operates within the U.S. system. Now, I work with immersive technology, the kind you'd normally see in galleries or museums, and we’re bringing it into healthcare settings. The goal is to make healthcare more interactive and reimagine what the rehabilitation journey can look like.
How do you define entrepreneurship within the healthcare context, and does it feel different from entrepreneurship in other industries?
Healthcare moves slowly — and that's by design. There are layers of regulation from hospitals, insurance companies, and patient advocacy frameworks, and every decision you make can directly impact someone's life. That demands a level of caution that you don't always find in other industries.
But beyond regulation, what makes healthcare entrepreneurship different is how adoption actually happens. Patients aren't your only users; clinicians, nurses, administrators all interact with your product differently, and most of them are too stretched to give you the benefit of the doubt. When we deployed our system across multiple sites, we learned quickly that selling a product and getting it used are two completely different challenges. Some teams close the deal and walk away. But the sites where our product actually stuck were the ones where we stayed, adapting to their specific workflows, earning trust with frontline staff, and iterating on the ground. Healthcare entrepreneurship isn't just about building something that works. It's about committing to the slow, unglamorous work of making it fit.
So when you're designing or delivering something in a healthcare setting, you have to think deeply about your end user. Does a nurse have two hours to sit through a product demo? Does a clinician have time to listen to your pitch between patients? Those are real questions that should shape how you build and how you sell.
What do you see as the biggest unmet need in healthcare today that you believe an entrepreneur can realistically solve?
The biggest gap I keep seeing is between what healthcare knows and what frontline workers can actually use. The research exists. The protocols exist. But they don't reach the right person in the right format at the right time.
I worked on an adolescent overdose prevention initiative in New York. The evidence was solid. But the school nurse has five minutes between students. A 45-page protocol is a PDF nobody opens. The real question was: what are the three things the clinician absolutely needs to know, and how does it reach them in a format that fits their day?
That's not a scientific problem. It's a delivery problem. And those are often the problems entrepreneurs are best positioned to solve.
Where do you think the tension lies between innovation and patient safety, and how should founders navigate that?
Patient safety isn't a tradeoff against innovation – it's a design constraint from day one. The same way an architect doesn't treat structural integrity as something to add later, a healthcare product team should treat safety as the foundation that shapes every design decision, not a checkbox at the end.
What gives me some optimism is that most of the technology being built right now is designed to support clinicians, not replace them. The tools gaining real traction are those that reduce repetitive work like documentation, scoring, and pattern flagging, while keeping clinicians at the center of the decision-making process.
I believe that is the right direction, both from an operational and a safety perspective. When there's always a human reviewing the output, the workflow itself contains a safeguard against the system’s blind spots. In that sense, innovation and safety are not opposing forces. They reinforce one another.
How do you think about health equity when evaluating whether a new healthcare product or service is actually creating value?
Every device or solution requires hardware, infrastructure, and capital — and not every community has access to those resources. The question I always come back to is: could this reach my hometown?
I grew up in a smaller city with a handful of hospitals. We didn't have the budget to implement cutting-edge prototypes. So when I evaluate a product, I ask whether it's only viable for large, well-funded health systems, or whether it can extend its reach. Telehealth is a good example of something with real equity potential – being able to connect patients in underserved areas to specialists in major cities is a meaningful advancement. Accessibility isn't just a nice-to-have; it's a core measure of whether a product is actually creating value.
What role do you think patients should play in the design and development of healthcare solutions?
It depends on what you're building, but patients should always be part of the conversation if you're building for them. That said, their role is to inform the design direction, not to dictate the product spec. Listening to patients doesn't mean executing on every surface request. A rehabilitation patient might say "this exercise is boring", but the underlying issue might be that the feedback loop is too slow, the progress indicators aren't visible enough, or the environment feels too clinical. As a designer or PM, your job is to decode the real need behind the stated complaint and translate it into something the engineering team can build.
In my work across clinical and technical teams, I act as that bridge. I take the needs of clinicians, patients, and administrators and decompose them into specifications that engineers and researchers can execute on. That means understanding both languages: the clinician's workflow constraints and the engineer's technical constraints. The reason patients need to be in the room is that without them, both sides default to their own assumptions, and the product drifts away from the person it's supposed to serve.
If you were advising a first-time founder entering the healthcare space, what is the one thing you would tell them not to underestimate?
Implementation time — and everything it costs, in both time and money. A lot of promising ideas come from clinicians who team up with engineers to build something. The prototype works beautifully.
But then you try to bring it into real-world settings and the questions get harder: Will this scale to a thousand hospitals? Will it hold up for millions of patients? That scaling process is incredibly time-intensive, and it often gets glossed over in the excitement of early development.
On top of that, the people you need to adopt your product — clinicians, nurses, administrators — are operating on packed schedules. They don't have two hours for an onboarding session. They don't have bandwidth for a lengthy product pitch. If you're not designing for that reality, you'll hit a wall.
On outreach specifically: be strategic about who you approach first. Identify the stakeholder who will actually use your product day-to-day and lead with them. If your product genuinely improves their workflow, they become your advocate — and that kind of bottom-up endorsement carries far more weight in healthcare than a top-down mandate.
What do you think most founders get wrong about how clinicians actually use AI tools day to day?
Founders get excited about what the technology can do. Clinicians only care about whether it saves them time. That disconnect is where most clinical AI products fail. A developer sees a model that can analyze, predict, summarize, and flag. A clinician sees another thing they have to learn, log into, and check between patients. If your tool doesn't feel like a natural extension of what they're already doing, they won't fight it. They'll just ignore it. The other thing that gets overlooked is that 'user-friendly' in a clinical setting means something very specific. It means I can figure this out without training, it gives me what I need without extra steps, and it doesn't generate more work than it eliminates. That's a higher bar than most consumer tech, and it's a UX problem as much as a technical one. The best AI tools in healthcare won't be the most powerful ones. They'll be the ones clinicians forget are even there.
When you're evaluating whether a clinical product is ready to pilot, what signals tell you it's too early?
The clearest signal is when a team can talk about what their product does but can't walk you through how it fits into the specific daily workflow at the site where they want to pilot. Not the theoretical workflow — the actual one, with all its interruptions and workarounds. Another red flag: there's no plan for failure. Every clinical product will hit edge cases and bad inputs. If nobody's thought through what happens when the system gets it wrong and how the clinician recovers, you're not ready. And if the product only works smoothly when someone from the company is in the room guiding the user — that's a demo, not a pilot.
On the flip side, one positive signal I find interesting is when a problem starts showing up in conversations outside the industry — when non-technical people begin noticing it. That usually means it's real and widespread. Rehabilitation is a good example. For a long time, it meant repeating the same physical exercises over and over. Then people from game design and interaction design started asking: Why does this have to be a clinical conversation? Why can't it be an experience? That shift came from fresh eyes — and it's now becoming a real category.
Is there a decision you've seen a health system or product team make that looked smart on paper but failed in practice? What did it teach you?
Plenty. The most common pattern is a product that works well as a prototype but falls apart when it's deployed across different hospitals or cities. People have different levels of technical familiarity, different workflows, and different institutional cultures. Something that feels intuitive in one setting can feel completely foreign in another.
I've seen this pattern repeatedly with early-stage teams. The prototype works, the demo is impressive, everyone is excited, but not enough attention is paid to whether the system can actually be implemented consistently at scale. The team was still thinking like a research lab, chasing the best result under ideal conditions, when what’s really needed was a product mentality focused on testing for the worst case. A research outcome can succeed through one strong demonstration. A product has to work consistently across real patients, real staff, and real operational constraints. That shift from controlled environments to messy reality is where many healthcare startups struggle.
The lesson, at its core, is that a great idea is only as good as your implementation strategy.
